feat(consensus): implement ZIP 218 behind a build feature - #851

Implements ZIP 218 "25-second Block Target Spacing" (zcash/zips#1215),
gated on the new `zip218` cargo feature so a default build keeps today's
consensus. Even in a `zip218` build the rules stay dormant until NU7 has
an activation height on the configured network, which no production
network sets yet.

Block target spacing and issuance:

- `PostNU7PoWTargetSpacing` = 25 seconds, an NU7 era in `target_spacings`,
  and a `NU7PoWTargetSpacingRatio` of 3.
- `halving` folds over the per-era spacings instead of branching on
  Blossom, and `block_subsidy` scales by `era_spacing /
  pre_blossom_spacing`. Both are the spec's segmented sum with the common
  denominator factored out, so a future spacing change is one tuple, not
  another branch. Issuance per unit of wall-clock time is unchanged.

Difficulty:

- `PostNU7PoWAveragingWindow` = 102, and `PoWAveragingWindow` becomes a
  height-dependent function that `AdjustedDifficulty` consults for the
  mean target and the median timespan.
- `POW_ADJUSTMENT_BLOCK_SPAN` now covers the widest window the build can
  use, so a `zip218` build carries 113 predecessors of difficulty context
  from genesis and ignores the entries past the window in force at the
  candidate height. The span stays 28 in a default build.

Shielded action limits:

- Per-block limits of 330 Orchard actions, 300 Sapling spends + outputs,
  and 25 Sprout JoinSplits, plus a global shielded budget of 330 over
  `orchard + sapling_ios + 2 * joinsplits`.
- `shielded_action_limits_are_valid` runs over any iterator of
  transactions: the block verifier passes the whole block, and the
  transaction verifier passes one transaction, so the mempool rejects a
  transaction whose own counts can never be mined.
- `getblocktemplate` tracks the same limits through a `BlockTemplateLimits`
  struct, which replaces the three loose counters and the
  `TryUpdateBlockLimits` trait, so template selection cannot build a block
  the verifier would reject.

The non-consensus constants ZIP 218 recommends scaling (the expiry delta,
`MAX_REORG_LENGTH`, and the block download and retention windows) are left
for a follow-up.

…-reduction

# Conflicts:
#	Cargo.lock
#	crates/zakura-consensus/Cargo.toml
#	crates/zakura-header-chain/Cargo.toml
#	crates/zakura-network/Cargo.toml
#	crates/zakura-node-services/Cargo.toml
#	crates/zakura-rpc/Cargo.toml
#	crates/zakura-script/Cargo.toml
#	crates/zakura-state/Cargo.toml
#	crates/zakura-utils/Cargo.toml
#	crates/zakurad/Cargo.toml

* feat(consensus): implement ZIP 2003 with a configurable deprecation height

Implements ZIP 2003 "Disallow version 4 transactions". Zakura already
rejected V4 transactions at NU7, but the height was welded to the NU7
activation height. The NU7 scope polls offer three deprecation dates, so
`V4Deprecation` names the choice instead:

- `AtNu7`, the ZIP 2003 default and today's behaviour, resolving to the
  NU7 activation height. A network that does not activate NU7 keeps
  accepting V4 transactions.
- `AtHeight(height)`, for a network that activates NU7 and deprecates V4
  transactions later.
- `Never`, for a network that keeps accepting V4 transactions.

`verify_v4_transaction_network_upgrade` now rejects on the resolved
height rather than on the NU7 arm of its network upgrade match, so
Mainnet and the default Testnet keep the rule they have today.

Testnet configures the choice through `testnet_parameters.v4_deprecation`,
which accepts `"nu7"`, `"never"`, or a block height.

* docs(changelog): add the ZIP 2003 fragment

* fix(consensus): require an exact NU7 v4 boundary

* refactor(consensus): fix v4 deprecation at NU7

* refactor(consensus): gate v4 deprecation on experimental NU7

…-reduction